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BT’s eXtended Network Quality RTP Control Protocol Extended Reports 
(RTCP XR XNQ) 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


IESG Note 


The IESG has concerns about vendor code points allocation in this 
small namespace and might not approve similar documents in the 
future. 


Abstract 


This document describes an RTCP XR report block, which reports packet 
transport parameters. The report block was developed by BT for pre- 
standards use in BT’s next-generation network. This document has 
been produced to describe the report block in sufficient detail to 
register the block type with IANA in accordance with the 
Specification Required policy of RFC 3611. This specification does 
not standardise the new report block for use outside BT’s network. 
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Les 


Introduction 


A set of metrics of packet-transport quality has been defined by BT 
for pre-standards use in its network. These metrics are known as 
"XNOQ" for "eXtended Network Quality". This document defines an 
RTCP-XR Report Block to transport the XNQ measures from an RTP end 
system to its peer, using the extension mechanism defined in [1]. 


The metrics are designed to supplement the packet-loss metric in RTCP 
[2] and the roundtrip delay measurement provided by RTCP. They 
provide metrics for IP Packet Delay Variation based on the IPDV 
metric defined in [3], metrics reporting the activity of the RTP end 
system’s receiver’s jitter buffer, and metrics reporting "errored" 
and "severely errored" seconds. 


This document has been produced to describe the report block in 
sufficient detail to register the block type with IANA in accordance 
with the Specification Required policy of [1]. This specification 
does not standardise the new report block for use outside BT’s 
network. 


Work in progress on RTCP HR [5] is likely to obsolete these metrics 
and the RTCP-XR Report Block defined here. 


Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [4]. 


Extended Network Quality (XNQ) Report Block 


A set of metrics of packet-transport quality has been defined by BT 
for pre-standards use in its network. These metrics are known as 
"XNOQ" for "eXtended Network Quality". 


This document defines an RTCP-XR Report Block using the extension 
mechanism defined in [1]. The new Report Block provides transport of 
the XNQ measures from an RTP end system to its peer. 


The metrics are described in the following text. However, some 
additional explanation is required for the metrics vmaxdiff, vrange, 
vsum, and c, which measure aspects of packet delay variation. The 
metrics are based on the measure known as IP Packet Delay Variation 
(IPDV) defined in [3]. The IPDV of a packet is the amount by which 
the packet was delayed in the network, minus the amount a reference 
packet was delayed in the network. The reference packet is usually 
the first packet of the connection. IPDV is a signed quantity. 
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The metric vrange is the difference (longest minus shortest) between 
the longest and shortest network packet delays seen over the duration 
of the connection to date. The metric vrange is usually a positive 
quantity, but may be zero if the packet delay is exactly constant 
over the lifetime of the connection to date. 


The metric vmaxdiff is found as follows. For each RTCP measurement 
cycle, find the difference (longest minus shortest) between the 
longest and shortest network packet delays within that measurement 
cycle. These differences are usually all positive quantities, but a 
difference may be zero if the packet delay is exactly constant 
throughout the measurement cycle. Take the set of these differences 
and find the maximum, which is vmaxdiff. The metric vmaxdiff is also 
usually a positive quantity, but will be zero if all the members of 
the set of per-cycle differences are zero. 


The metric vsum is simply the sum of the per-RTCP-cycle differences, 
which were obtained to find vmaxdiff as described above. The metric 
c is the number of per-RTCP-cycle differences, that is, the 
cardinality of the set of differences. The two metrics vsum and c 
allow calculation of vsum/c, the average IPDV per RTCP measurement 
cycle. 


The format of the report is as shown in Figure 1. 


0 1 2 3 
01234567890123456789012345678<9041 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++H 

| BT=8 | reserved | block length = 8 

tatetetetetatetetetatatatetatatatetatatatataetatatatetatatetatatet 
| begin_seq | end_seq | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++HHHHHMHHHH MHH 
| vmaxdiff | vrange | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++HHHHHHM M 
| vsum | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ta ta tata tata tata tata tata t—t-t 
| c jbevents | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| reserved | tdegnet | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| reserved | tdegjit | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++HHHHHH H 
: 
: 


reserved | es | 
Foto tata tr tartar ta toto ta ta tatantatatatcta ta tata tata ta totatatatotat 
reserved | ses | 
tStatatataetatatatatatatatatatatatatatatatatatatatatetatatataetat 


Figure 1 
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The report consists of an RTCP-XR block header and a single 8-word 
sub-block. 


block type (BT): 8 bits 
An XNQ Metrics Report Block is identified by the constant 8. 

reserved: 8 bits 
These fields are reserved for future definition. In the absence 
of such a definition, the bits in these fields MUST be set to zero 
and MUST be ignored by the receiver. 

block length: 16 bits 
Defined in Section 3 of [1]. 

begin_seq: 16 bits 
As defined in Section 4.1 of [1]. 

end_seq: 16 bits 
As defined in Section 4.1 of [1]. 

vmaxdiff: 16 bits unsigned 
Largest IPDV difference seen to date within a single RTCP 
measurement cycle, measured in RTP timestamp units. If the 
measured value exceeds OxFFFE, the value OxFFFF should be reported 
to indicate an over-range measurement. 

vrange: 16 bits unsigned 
Largest IPDV difference over the lifetime of the RTP flow to date, 
measured in RTP timestamp units. If the measured value exceeds 
OxFFFE, the value OxFFFF should be reported to indicate an over- 
range measurement. 

vsum: 32 bits unsigned 
Sum of the peak IPDV difference values within each RTCP cycle, 
summed over RTCP cycles over the lifetime of the RTP flow to date. 


If the measured value exceeds OxFFFFFFFE, the value OxFFFFFFFF 
should be reported to indicate an over-range measurement. 
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16 bits unsigned 


Number of RTCP cycles over which vsum was accumulated. If the 
measured value exceeds OxFFFE, the value OxFFFF should be reported 
to indicate an over-range measurement. 


jbevents: 16 bits unsigned 


Cumulative number of jitter buffer adaptation events over the 
lifetime of the RTP flow to date. If the measured value exceeds 
OxFFFE, the value OxFFFF should be reported to indicate an over- 
range measurement. 


tdegnet: 24 bits unsigned 


The total time in sample periods affected either by packets 
unavailable due to network loss, or late delivery of packets, 
since the start of transmission. If the measured value exceeds 
OxFFFFFE, the value OxFFFFFF should be reported to indicate an 
over-range measurement. 


tdegjit: 24 bits unsigned 


es: 


The total time in sample periods degraded by jitter buffer 
adaptation events, e.g., where the jitter buffer either plays out 
a sample sequence not originating at the transmitter, repeats 
samples, or chooses not to play out a sample sequence that was 
sent by the transmitter. If the measured value exceeds OxFFFFFE, 
the value OxFFFFFF should be reported to indicate an over-range 
measurement. 


24 bits unsigned 


cumulative seconds affected by "unavailable packet" events over 
the lifetime of this ephemeral, to date. If the measured value 
exceeds OxFFFFFE, the value OxFFFFFF should be reported to 
indicate an over-range measurement. 


ses: 24 bits unsigned 


Hunt 


cumulative seconds affected by severe "unavailable packet" events 
over the lifetime of this ephemeral, to date. If the measured 
value exceeds OxFFFFFE, the value OxFFFFFF should be reported to 
indicate an over-range measurement. 
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4. IANA Considerations 


IANA has allocated the number 8 within the registry "RTP Control 
Protocol Extended Reports (RTCP XR) Block Types" to the RTCP XR 
report block described here. This registry is defined in [1]. 


5. Security Considerations 


It is believed that this proposed RTCP XR report block introduces no 
new security considerations beyond those described in [1]. Some of 
the considerations in [1] do not apply to this report block. 
Specifically, XNQ does not provide per-packet statistics so the risk 
to confidentiality documented in Section 7, paragraph 3 of [1] does 
not apply, and XNQ packets cannot be very large so the risk of denial 
of service documented in Section 7, paragraph 7 of [1] does not 


apply. 
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Full Copyright Statement 
Copyright (C) The IETF Trust (2007). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 
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